System and method for transferring a line of credit balance to a cash account

ABSTRACT

The present invention provides an automated system configured to facilitate transfers of cash value from one or more lines of credit to one or more deposit accounts or payment systems. An automated system ensures that requested funds are available in a customer&#39;s one or more lines of credit and electronically deposits the requested funds into one or more designated deposit accounts or payment systems. An automated system provides a means for customers to manage lines of credit, setup transfer transactions, define rules governing transfers and view transactional history. The automated system, in network connection with the lending organization&#39;s backend systems, may authenticate customer identities and credit accounts as well as insure that the requested funds are available for transfer into a deposit account.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of, claims priority to and thebenefit of, U.S. Ser. No. 13/673,534 entitled “SYSTEM AND METHOD FORTRANSFERRING A LINE OF CREDIT BALANCE TO A CASH ACCOUNT” filed on Nov.9, 2012. The '534 application is a continuation of, claims priority toand the benefit of, U.S. Pat. No. 8,332,316 issued on Dec. 11, 2012 (akaU.S. Ser. No. 13/458,841 filed on Apr. 27, 2012) entitled “SYSTEM ANDMETHOD FOR TRANSFERRING A LINE OF CREDIT BALANCE TO A CASH ACCOUNT.” The'316 patent is a continuation of, claims priority to and the benefit of,U.S. Pat. No. 8,190,517 issued on May 29, 2012 (aka U.S. Ser. No.10/906,674 filed on Mar. 1, 2005) and entitled “SYSTEM AND METHOD FORTRANSFERRING A LINE OF CREDIT BALANCE TO A CASH ACCOUNT”. The '517patent claims priority to, and the benefit of, U.S. ProvisionalApplication Ser. No. 60/521,352 filed Apr. 7, 2004 and entitled“Automated Clearinghouse System and Method.” All of which are herebyincorporated by reference in their entirety.

FIELD OF INVENTION

The present invention relates generally to facilitating automatedelectronic funds transfers from lines of credit to deposit accounts, andmore particularly, to a system and method for customer management ofcredit line funds transfers whereby transfer requests may be processedthrough an automated clearinghouse, depositing funds into a variety ofdifferent accounts and debiting a customer's credit lines.

BACKGROUND OF THE INVENTION

For years, electronic funds transfers have enabled customers to sendmoney worldwide in real-time. In 1871, Western Union began offeringcustomers electronic funds transfer service via telegraph. Since thattime, the communication means has changed only slightly and the utilityof “wire services” have increased in step with the growth of worldtrade. Financial institutions have been developing new technologies toencourage the transfer of funds in a line of credit to retailers andservice providers. It is in the best interest of credit providers aswell as their credit-worthy customers to provide more convenient andreadily available methods for conducting transactions against a line ofcredit. Circa 1950, American Express and Diners Club introduced thefirst charge cards. The charge cards were intended to replace cashcurrency in limited circumstances allowing customers to facilitatecashless purchases that would later be paid in cash. These cards werelimited in that they were only accepted by a small number ofgeographically bound businesses. Standards for magnetic strips wereestablished in the early 1970's and credit cards gained wide appeal fromcustomers and greater acceptance from venders.

Banks most often allow their customers to transfer funds from a line ofcredit into a deposit account. However, these types of transfers arelimited in that they only allow transfers of funds from a customer'sline of credit into an account which is owned by the same customer.Further, most banks will not allow an online transfer from anunaffiliated line of credit into a customers deposit account. In otherwords, a transfer of funds from a credit line offered by bank A into adeposit account of bank B would not be possible online. This type oftransfer would likely require the customer to personally retrieve thefunds from Bank A and then personally deposit the funds into the accountat Bank B.

While the prior art provides a means for transferring a balance from acredit line to an account within the same institution, it does notprovide the flexibility needed by increasingly sophisticated consumerswho may maintain a number of different financial accounts with anynumber of providers. Therefore, a need exists for a system and method toprovide credit line customers a means to transfer cash from one or morelines of credit into a variety of secondary accounts including depositaccounts owned by the customer, deposit accounts owned by others, andpayment systems used in retailing.

SUMMARY OF THE INVENTION

The present invention overcomes the limitations and problems of theprior art by providing a system and method for transferring funds fromlines of credit to direct deposit accounts. The system may facilitatetransfers between at least one consumer and/or business credit line andat least one deposit account or payment system. A customer through anetworked connection with an automated system initiates the transfer offunds from a consumer and/or business line of credit. The automatedsystem, through a connection with the line of credit provider, obtainsauthentication of the customer and authorization for the transfer. Theautomated system then conducts a transfer of funds to one or moredesignated deposit accounts or payment systems via an ACH network.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be derived byreferring to the detailed description and claims when considered inconnection with the Figures, wherein like reference numbers refer tosimilar elements throughout the Figures, and:

FIG. 1 is a block diagram illustrating a high level view of exemplarymajor system components for an automated system for processing creditline transfer transactions;

FIG. 2 is a block diagram illustrating a detailed view of exemplarymajor system components for an automated system for processing creditline transfer transactions;

FIG. 3 is a flow chart illustrating an exemplary method for enrollingwith a deposit account to conduct transfer transactions;

FIG. 4 is a flow chart illustrating an exemplary method for interactingwith an automated system to manage accounts and initiate transfertransactions;

FIG. 5 is a flow chart illustrating a high level view of an exemplarymethod for managing an enrolled deposit account; and,

FIG. 6 is a flow chart illustrating an exemplary method for facilitatinga transfer of funds from a line of credit to a deposit account.

DETAILED DESCRIPTION

The detailed description of exemplary embodiments of the inventionherein makes reference to the accompanying drawings, which show theexemplary embodiment by way of illustration and its best mode. Whilethese exemplary embodiments are described in sufficient detail to enablethose skilled in the art to practice the invention, it should beunderstood that other embodiments may be realized and that logical andmechanical changes may be made without departing from the spirit andscope of the invention. Thus, the detailed description herein ispresented for purposes of illustration only and not of limitation.

System

In general, the invention includes a system and method for facilitatingelectronic transfers of values (e.g., cash values) from one or morecredit lines to one or more secondary accounts via an automated systemsuch as an automated clearing house (ACH 110). While the invention maybe described with respect to cash value transfers, the invention alsocontemplates transfers of anything of value such as, for example,loyalty points, merchant specific points or currency, securities,negotiable instruments, gift cards, coupons, digital funds, and/orforeign currency (including any conversions). With reference to FIG. 1,the invention may enable a customer 100 to facilitate a transfertransaction through a personal computer 105 in networked connection toACH 110. ACH 110 may comprise a number of hardware and/or softwarecomponents configured to process transfer requests by transmitting datato and receiving data from a number of backend systems 140. Backendsystems 140 may comprise any number of hardware and/or softwarecomponents configured to manage credit transactions for a creditprovider. ACH 110 may include, in one embodiment, one or more firewall115, services server 120, database 125, report generator 130 andmiddleware 135.

As will be appreciated by one of ordinary skill in the art, the presentinvention may be embodied as a customization of an existing system, anadd-on product, upgraded software, a stand alone system (e.g., kiosk), adistributed system, a method, a data processing system, a device fordata processing, and/or a computer program product. Accordingly, thepresent invention may take the form of an entirely software embodiment,an entirely hardware embodiment, or an embodiment combining aspects ofboth software and hardware. Furthermore, the present invention may takethe form of a computer program product on a computer-readable storagemedium having computer-readable program code means embodied in thestorage medium. Any suitable computer-readable storage medium may beutilized, including hard disks, CD-ROM, optical storage devices,magnetic storage devices, and/or the like.

An account manager, as used herein, may include any individual,business, entity, software and/or hardware that owns, manages orcontrols one or more components of the system. The account manager mayown or manage some or all of the hardware and software components of thesystem, however this is not necessary. For example, the account managermay own or manage a component which is hosted by a third-party on acontract basis.

A customer computer 105 may include any software and/or hardware thatfacilitate communications and/or transactions between a customer 100 andthe services of ACH 110. Customer computer 105 may interface with ACH110 via any communication protocol, device or method discussed herein orknown in the art. In one embodiment, a customer computer 105 mayinterface with ACH 110 via an Internet browser.

An Internet browser may comprise any hardware and/or software suitablyconfigured to facilitate input, receipt and/or review of any informationrelated to ACH 110 or any information discussed herein. Such Internetbrowsers comprise software installed within a computing unit or systemto conduct online transactions and communications. These computing unitsor systems may take the form of a computer or set of computers, althoughother types of computing units or systems may be used, includinglaptops, notebooks, hand held computers, set-top boxes, workstations,computer-servers, main frame computers, mini-computers, PC servers,pervasive computers, network sets of computers, and/or the like.

Firewall 115 may include any hardware and/or software suitablyconfigured to protect ACH 110 components from users of other networksand provide limited or restricted access to ACH 110 components fromcustomer computers 105. Firewall 115 may reside in varyingconfigurations including Stateful Inspection, Proxy based and PacketFiltering among others. Firewall 115 may be integrated within ACH 110,other system components or may reside as a stand-alone component.

Services server 120 may include any hardware and/or software suitablyconfigured to process credit transfer transactions, manage processesand/or facilitate communications between external entities andcomponents within a services server 120. Services server 120 mayinterface directly or indirectly with customer computer 105, database125, report generator 130 and middleware 135. Services server 120 may beimplemented as a single computing unit in a single geographic locationor may comprise any number of computing units and/or components locatedtogether or residing in separate geographic locations. Services server120 may be an Internet server configured to receive, process and sendHTML streams. Further, services server 120 may exist as one or moreservers, mainframes or any other computing device configured to send andreceive data between itself and one or more Internet servers,workstations, personal computers and the like.

In one embodiment, a services server 120 may be configured to dispatchrequests to components behind a firewall 115 in order to prevent directaccess to ACH 110 components. A services server 120 may first processdata transmissions between a customer computer 105 and the components ofACH 110. Services server 120 may invoke computer code to process data,request data or commit data to a database 125. Further, services server120 may invoke computer code to construct a report using a reportgenerator 130. Report generator 130 may request data from a database 125to compile pre-configured and/or ad-hoc reports.

For simplicity, services server 120, database 125, report generator 130,and middleware 135 are illustrated and described herein as individualcomponents within ACH 110. Practitioners will appreciate that thevarious system components of ACH 110 may reside within memory structuresof services server 120 or may comprise any number of computing systemsand architectures. Further, it should be appreciated that a customercomputer 105 may or may not be in networked directly with ACH 110. Acustomer computer may connect through any number of Internet servers,routers, hubs and the like. In one embodiment, customer computer 105 mayconnect with a third party system and a third party system may benetworked with any number of ACH 110 systems.

Database 125 may include any hardware and/or software suitablyconfigured to facilitate storing service data and/or audit data relatingto customer 100. Customer 100 data may comprise any information whichmay be used to identify a customer, validation credentials, creditaccounts, transaction records and the like. For simplicity, database 125is illustrated and described herein as a single database. One skilled inthe art will appreciate that ACH 110 may employ any number of databasesin any number of configurations. Further, any databases discussed hereinmay be any type of database, such as relational, hierarchical,graphical, object-oriented, and/or other database configurations. Commondatabase products that may be used to implement the databases includeDB2 by IBM (White Plains, N.Y.), various database products availablefrom Oracle Corporation (Redwood Shores, Calif.), Microsoft Access orMicrosoft SQL Server by Microsoft Corporation (Redmond, Wash.), or anyother suitable database product. Moreover, the databases may beorganized in any suitable manner, for example, as data tables or lookuptables. Each record may be a single file, a series of files, a linkedseries of data fields or any other data structure. Association ofcertain data may be accomplished through any desired data associationtechnique such as those known or practiced in the art. For example, theassociation may be accomplished either manually or automatically.Automatic association techniques may include, for example, a databasesearch, a database merge, GREP, AGREP, SQL, and/or the like. Theassociation step may be accomplished by a database merge function, forexample, using a “key field” in pre-selected databases or data sectors.

More particularly, a “key field” partitions the database according tothe high-level class of objects defined by the key field. For example,certain types of data may be designated as a key field in a plurality ofrelated data tables and the data tables may then be linked on the basisof the type of data in the key field. In this regard, the datacorresponding to the key field in each of the linked data tables ispreferably the same or of the same type. However, data tables havingsimilar, though not identical, data in the key fields may also be linkedby using AGREP, for example. In accordance with one aspect of thepresent invention, any suitable data storage technique may be utilizedto store data without a standard format. Data sets may be stored usingany suitable technique, including, for example, storing individual filesusing an ISO/IEC 7816-4 file structure; implementing a domain whereby adedicated file is selected that exposes one or more elementary filescontaining one or more data sets; using data sets stored in individualfiles using a hierarchical filing system; data sets stored as records ina single file (including compression, SQL accessible, hashed via one ormore keys, numeric, alphabetical by first tuple, etc.); block of binary(BLOB); stored as ungrouped data elements encoded using ISO/IEC 7816-6data elements; stored as ungrouped data elements encoded using ISO/IECAbstract Syntax Notation (ASN.1) as in ISO/IEC 8824 and 8825; and/orother proprietary techniques that may include fractal compressionmethods, image compression methods, etc.

In one exemplary embodiment, the ability to store a wide variety ofinformation in different formats is facilitated by storing theinformation as a Block of Binary (BLOB). Thus, any binary informationcan be stored in a storage space associated with a data set. Asdiscussed above, the binary information may be stored on the financialtransaction instrument or external to but affiliated with the financialtransaction instrument. The BLOB method may store data sets as ungroupeddata elements formatted as a block of binary via a fixed memory offsetusing either fixed storage allocation, circular queue techniques, orbest practices with respect to memory management (e.g., paged memory,least recently used, etc.). By using BLOB methods, the ability to storevarious data sets that have different formats facilitates the storage ofdata associated with the financial transaction instrument by multipleand unrelated owners of the data sets. For example, a first data setwhich may be stored may be provided by a first issuer, a second data setwhich may be stored may be provided by an unrelated second issuer, andyet a third data set which may be stored, may be provided by an thirdissuer unrelated to the first and second issuer. Each of these threeexemplary data sets may contain different information that is storedusing different data storage formats and/or techniques. Further, eachdata set may contain subsets of data, which also may be distinct fromother subsets.

As stated above, in various embodiments of the present invention, thedata can be stored without regard to a common format. However, in oneexemplary embodiment of the present invention, the data set (e.g., BLOB)may be annotated in a standard manner when provided for manipulating thedata onto the financial transaction instrument. The annotation maycomprise a short header, trailer, or other appropriate indicator relatedto each data set that is configured to convey information useful inmanaging the various data sets. For example, the annotation may becalled a “condition header”, “header”, “trailer”, or “status”, herein,and may comprise an indication of the status of the data set or mayinclude an identifier correlated to a specific issuer or owner of thedata. In one example, the first three bytes of each data set BLOB may beconfigured or configurable to indicate the status of that particulardata set; e.g., LOADED, INITIALIZED, READY, BLOCKED, REMOVABLE, orDELETED. Subsequent bytes of data may be used to indicate for example,the identity of the issuer, user, transaction/membership accountidentifier or the like. Each of these condition annotations are furtherdiscussed herein.

The data set annotation may also be used for other types of statusinformation as well as various other purposes. For example, the data setannotation may include security information establishing access levels.The access levels may, for example, be configured to permit only certainindividuals, levels of employees, companies, or other entities to accessdata sets, or to permit access to specific data sets based on thetransaction, provider, issuer, user or the like. Furthermore, thesecurity information may restrict/permit only certain actions such asaccessing, modifying, and/or deleting data sets. In one example, thedata set annotation indicates that only the data set owner or the userare permitted to delete a data set, various identified providers arepermitted to access the data set for reading, and others are altogetherexcluded from accessing the data set. However, other access restrictionparameters may also be used allowing various entities to access a dataset with various permission levels as appropriate.

A stand-alone interaction device configured to add, delete, modify, oraugment the data in accordance with the header or trailer may receivethe data, including the header or trailer. As such, in one embodiment,the header or trailer is not stored on the transaction device along withthe associated issuer-owned data but instead the appropriate action maybe taken by providing to the transaction instrument user at thestand-alone device, the appropriate option for the action to be taken.The present invention may contemplate a data storage arrangement whereinthe header or trailer, or header or trailer history, of the data isstored on the transaction instrument in relation to the appropriatedata.

Report generator 130 may include any hardware and/or software suitablyconfigured to produce reports from information stored in one or moredatabases 125. Report generators are commercially available and known inthe art. Report generator 130 may provide printed reports, web access toreports, graphs, real-time information, raw data, batch informationand/or the like. Report generator 130 may be implemented throughcommercially available hardware and/or software, through custom hardwareand/or software components, or through a combination thereof. Further,report generator 130 may reside as a standalone system within ACH 110 ormay be a software component installed in a services server 120. Reportgenerator 130 may be configured to process requests from customercomputer 105 transaction histories among other things. Data extractedfrom database 125 may be formatted by report generator 130 andtransmitted from a services server 120 to a customer computer 105. Asillustrated and discussed herein, report generator 130 may process andformat data relating to one or more customer 100 transactions in amanner to be received by a customer computer 105. However, practitionerswill appreciate that report generator 130 may also produce any number ofpre-configured and/or ad-hoc reports, which may be transmitted directlyor indirectly to customer computer 105.

Middleware 135 may include any hardware and/or software suitablyconfigured to facilitate communications and/or process transactionsbetween disparate computing systems. Middleware components arecommercially available and known in the art. Middleware 135 may beimplemented through commercially available hardware and/or software,through custom hardware and/or software components, or through acombination thereof. Middleware 135 may reside in a variety ofconfigurations and may exist as a standalone system or may be a softwarecomponent residing within a services server 120. Middleware 135 may beconfigured to process transactions between services server 120 and othersystems and components within ACH 110 and/or systems and componentsresiding in backend systems 140.

Further, middleware 135 may contain logic for navigating, extractingdata and entering data into various user interface screens and/orwebpages. This type of logic most often uses patterns within a userinterface and/or webpage to recognize and determine what command oraction to execute next. A developer may create and define sequences ofsuch patterns and create corresponding scripts providing instructions onwhat commands or actions to execute when each defined pattern isrecognized. Practitioners will appreciate that there are a number ofcommercially available software tools, which facilitate this type ofcommunication between disparate computing systems. Such tools are oftenreferred to as pattern recognition systems or, screen-scrapers.

FIG. 2 is a block diagram illustrating a detailed view of the majorsystem components for an automated clearinghouse for processing creditline transfer transactions. The system components may best be describedaccording to functional groups such as, customer 200, ACH 205, backendsystems 215 and receiving systems 280. Practitioners will appreciatethat for simplicity processes that may be performed by multiplecomponents may be illustrated and discussed herein as single components.For example, AR systems 270 are presented as a single block component inFIG. 2, however AR systems 270 may comprise any number of computingplatforms and systems. Further, the sequences for processing credit linetransfer transactions may occur in sequenced order, simultaneously, or acombination thereof and therefore does not limit the scope of theinvention.

Customer 200 may represent any number of individual client systems whichconnect to ACH 205 in order to facilitate management of credit linetransfer services. As illustrated, a customer 200 may interact with ACH205 through a service delivery platform client 220 (SDP) such as, forexample, an ATM or kiosk. A customer 200 may also interact with a ACH205 through a voice recognition client 225 employing telephonytechnology enabling a customer 100 to manage credit line transactionservices through a telephone connection and issuance of touch-toneand/or voice commands. Further, client 200 may interact with ACH 205 viaa web client 230 connections to ACH 205 over the Internet. These andother various technologies for interacting with a server are known inthe art will not be discussed at length herein.

Referring to FIG. 1, transmissions of data between customer computer 105and services server 120 may pass through a firewall 115 in order toensure the security of ACH 110 components. Referring again to FIG. 2,services server 120 may initialize various services in response totransmissions of data between two or more components of the invention.Services, as used herein, may include any hardware and/or softwaresuitably configured to process specific types of information. Servicesmay apply computing logic in order to process information throughvarious steps including, for example, compiling, sending, receiving,configuring and validating. Services may comprise program code storedwithin memory components of services server 235, or may reside in othercomputing components. Further, services may comprise Java servlets,JSPs, ASPs and/or any other server-side programming architecture.

Verification service 240 may receive and process information relating toauthentication of customer identities and credit account credentials.Verification service may exchange and process data as provided by acustomer 200 and interact through middleware 260 with a cardauthorization system/funds access system (CAS/FAS) 275.

Limit service 245 may receive and process information relating to creditline limits in order to grant or deny a transfer request. For example,if a customer 200 connects to ACH 205 and initiates a transfer of $2,000from a business line of credit into a personal deposit account, limitservice 245 may receive the request and interact with CAS/FAS 275 toensure that the customer's available credit limit meets or exceeds$2,000. Limit service 245 may also restrict, change or deny requeststhat are, for example, above the credit limit. Limit service 245 mayinteract with various backend systems 215 through middleware 260.

Enlist service 255 may receive and process information relating tocustomer 200 enlistment for a new line of credit or other servicesoffered by a credit provider. Enlist service 255 may interact withvarious backend systems 215 in order to determine a customer's 200credit worthiness, payment histories, participation in other services,and the like. Enlist service 255 may interact through middleware 260with any number of other backend systems which are known in the art forautomated enrollment into a credit related program.

A credit line transfer request may include specifics concerning areceiving account 280 where transferred funds are to be deposited.Receiving account 280 may include a customer's deposit account 285, ajointly owned account, a deposit account not belonging to a customer290, a vendor account 295 or payment systems and any number of otheraccounts capable of receiving electronic funds transfers. For example, acustomer 200 who wishes to engage in a purchase for an item, wherein theseller is not a retailer and therefore cannot accept credit cards, maydo so by connecting to ACH 205 and initiating a transfer of cash fromher personal credit line to the seller's deposit account 290.

The various system components discussed herein may include one or moreof the following: a server or other computing systems including aprocessor for processing digital data; a memory coupled to saidprocessor for storing digital data; an input digitizer coupled to theprocessor for inputting digital data; an application program stored insaid memory and accessible by said processor for directing processing ofdigital data by said processor; a display device coupled to theprocessor and memory for displaying information derived from digitaldata processed by said processor; and a plurality of databases. Variousdatabases used herein may include: user data, debt data, income data,provider data; financial institution data and/or like data useful in theoperation of the present invention. As those skilled in the art willappreciate, user computer may include an operating system (e.g., WindowsNT, 95/98/2000, OS2, UNIX, Linux, Solaris, MacOS, etc.) as well asvarious conventional support software and drivers typically associatedwith computers. User computer can be in a home or business environmentwith access to a network. In an exemplary embodiment, access is througha network or the Internet through a commercially available web-browsersoftware package.

As used herein, the term “network” shall include any electroniccommunications means which incorporates both hardware and softwarecomponents of such. Communication among the parties in accordance withthe present invention may be accomplished through any suitablecommunication channels, such as, for example, a telephone network, anextranet, an intranet, Internet, point of interaction device (point ofsale device, personal digital assistant, cellular phone, kiosk, etc.),online communications, off-line communications, wireless communications,transponder communications, local area network (LAN), wide area network(WAN), networked or linked devices and/or the like. Moreover, althoughthe invention is frequently described herein as being implemented withTCP/IP communications protocols, the invention may also be implementedusing IPX, AppleTalk, IP-6, NetBIOS, OSI or any number of existing orfuture protocols. If the network is in the nature of a public network,such as the Internet, it may be advantageous to presume the network tobe insecure and open to eavesdroppers. Specific information related tothe protocols, standards, and application software utilized inconnection with the Internet is generally known to those skilled in theart and, as such, need not be detailed herein. See, for example, DILIPNAIK, INTERNET STANDARDS AND PROTOCOLS (1998); JAVA 2 COMPLETE, variousauthors, (Sybex 1999); DEBORAH RAY AND ERIC RAY, MASTERING HTML 4.0(1997); and LOSHIN, TCP/IP CLEARLY EXPLAINED (1997) and DAVID GOURLEYAND BRIAN TOTTY, HTTP, THE DEFINITIVE GUIDE (2002), the contents ofwhich are hereby incorporated by reference.

The various system components may be independently, separately orcollectively suitably coupled to the network via data links whichincludes, for example, a connection to an Internet Provider (ISP) overthe local loop as is typically used in connection with standard modemcommunication, cable modem, Dish networks, ISDN, Digital Subscriber Line(DSL), or various wireless communication methods. See, e.g., GILBERTHELD, UNDERSTANDING DATA COMMUNICATIONS (1996), hereby incorporated byreference. It is noted that the network may be implemented as othertypes of networks, such as an interactive television (ITV) network.Moreover, the system contemplates the use, sale or distribution of anygoods, services or information over any network having similarfunctionality described herein.

The computers discussed herein may provide a suitable website or otherInternet-based graphical user interface which is accessible by users,hosts or operators of the system. In one embodiment, the MicrosoftInternet Information Server (IIS), Microsoft Transaction Server (MTS),and Microsoft SQL Server, are used in conjunction with the Microsoftoperating system, Microsoft NT web server software, a Microsoft SQLServer database system, and a Microsoft Commerce Server. Additionally,components such as Access or Microsoft SQL Server, Oracle, Sybase,Informix MySQL, InterBase, etc., may be used to provide an Active DataObject (ADO) compliant database management system.

Any of the communications, inputs, storage, databases or displaysdiscussed herein may be facilitated through a website having web pages.The term “web page” as it is used herein is not meant to limit the typeof documents and applications that might be used to interact with theuser. For example, a typical website might include, in addition tostandard HTML documents, various forms, Java applets, JavaScript, activeserver pages (ASP), common gateway interface scripts (CGI), extensiblemarkup language (XML), dynamic HTML, cascading style sheets (CSS),helper applications, plug-ins, and the like. A server may include a webservice, which receives a request from a web server, the requestincluding a URL (http://yahoo.com/stockquotes/ge) and an IP address(123.56.789). The web server retrieves the appropriate web pages andsends the data or applications for the web pages to the IP address. Webservices are applications, which are capable of interacting with otherapplications over a communications means, such as the Internet. Webservices are typically based on standards or protocols such as XML,SOAP, WSDL and UDDI. Web services methods are well known in the art, andare covered in many standard texts. See, e.g., ALEX NGHIEM, IT WEBSERVICES: A ROADMAP FOR THE ENTERPRISE (2003), hereby incorporatedherein by reference.

The present invention may be described herein in terms of functionalblock components, screen shots, optional selections and variousprocessing steps. It should be appreciated that such functional blocksmay be realized by any number of hardware and/or software componentsconfigured to perform the specified functions. For example, the presentinvention may employ various integrated circuit components, e.g., memoryelements, processing elements, logic elements, look-up tables, and thelike, which may carry out a variety of functions under the control ofone or more microprocessors or other control devices. Similarly, thesoftware elements of the present invention may be implemented with anyprogramming or scripting language such as C, C++, Java, COBOL,assembler, PERL, Visual Basic, SQL Stored Procedures, extensible markuplanguage (XML), with the various algorithms being implemented with anycombination of data structures, objects, processes, routines or otherprogramming elements. Further, it should be noted that the presentinvention may employ any number of conventional techniques for datatransmission, signaling, data processing, network control, and the like.Still further, the invention could be used to detect or prevent securityissues with a client-side scripting language, such as JavaScript,VBScript or the like. For a basic introduction of cryptography andnetwork security, the following may be helpful references: (1) “AppliedCryptography: Protocols, Algorithms, And Source Code In C,” by BruceSchneier, published by John Wiley & Sons (second edition, 1996); (2)“Java Cryptography” by Jonathan Knudson, published by O'Reilly &Associates (1998); (3) “Cryptography & Network Security: Principles &Practice” by William Stalling, published by Prentice Hall; all of whichare hereby incorporated by reference.

Each customer may be equipped with a computing device in order tointeract with the system and facilitate online credit line transfertransactions. The customers each have a computing unit in the form of apersonal computer, although other types of computing units may be usedincluding laptops, notebooks, hand held computers, set-top boxes,cellular telephones, touch-tone telephones and the like. A systemadministrator may have a computing unit implemented in the form of acomputer-server, although other implementations are contemplated by theinvention. The account manager has a computing center shown as a server.However, account manager computing center may be implemented in otherforms, such as a mini-computer, a PC server, a network of computerslocated in the same of different geographic locations, or the like.Moreover, the system contemplates the use, sale or distribution of anyservices or information over any network having similar functionalitydescribed herein

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function specified in the flowchart block or blocks.The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions specified in theflowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems which perform thespecified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions.

Referring now to FIGS. 3-6, the process flows depicted are merelyexemplary embodiments of the invention and are not intended to limit thescope of the invention as described herein. For example, the stepsrecited in any of the method or process descriptions may be executed inany order and are not limited to the order presented. It will beappreciated that the following descriptions make appropriate referencesnot only to the steps depicted in FIGS. 3-6, but also to the varioussystem components as described above with reference to FIGS. 1-2.Further, illustrations of the process flows and the descriptions thereofmake reference to webpages, websites, web forms, prompts, etc.Practitioners will appreciate that the illustrated steps described belowmay exist in any number of configurations including the use of webpages,web forms, popup windows, prompts and the like. It should be furtherappreciated that the multiple steps as illustrated and described may becombined into single webpages but have been expanded for the sake ofsimplicity. In other cases, steps illustrated and described as singleprocess steps may be broken down into multiple webpages but have beencombined for simplicity.

FIG. 3 is a flow chart illustrating an exemplary method for enrolling touse ACH 205 in order to conduct line of credit transfer transactions.ACH 205 may require enrollment in order to maintain account information,provide security and provide for an audit trail for customer 200transfer transactions. A customer 200 may initiate the enrollmentprocess through a suitable network connection with an automated systemof the invention (step 300). In other embodiments, the invention mayallow enrollment through any other component of the system. FIG. 3illustrates an exemplary enrollment process as it may be conductedthrough an Internet web browser. Practitioners will appreciate that asimilar process flow may also be applicable to any other device capableof interacting with ACH 205 such as, for example, a PDA, telephone, cellphone, kiosk, ATM, and the like.

On a website homepage for ACH 205, customer 200 may select to enroll ina transfer service (step 305). Methods for browser interactions throughwebpages are known in the art and may include graphical user interface(GUI) elements such as, for example, buttons, menus, drop-down lists,hyperlinks, and the like. Following a selection to enroll in a transferservice (step 305), a customer 200 may be presented terms and conditions(step 310) and prompted to select whether or not they agree to abide bythe terms and conditions. Terms and conditions (step 310) may comprisedisclosure of fees, proper use and conduct rules, and various legaldisclaimers. If a customer 200 agrees to, and thereby accepts, the termsand conditions (step 315) then customer 200 may be returned to a webpagewhere they may again select to enroll in a transfer service (step 305)or exit from the website. If customer 200 accepts the terms andconditions (step 315), then customer 200 may be presented a web form andprompted to enter personal information (step 320). Personal informationmay include customer's 200 name, telephone number, email address,account information and the like.

In an exemplary embodiment, ACH 205 may be configured to allow customers200 to manage various lines of credit accounts from variousparticipating account managers. Under this scenario, for example, ACH205 may serve as an independent third party to customers 200 of variousaccount managers, such as American Express, Visa, MasterCard, Discoveras well as any other lending organization offering personal or businesslines of credit. In another embodiment, ACH 205 may be exclusivelyaccessible by customers 200 of a single account manager. For example,American Express may own ACH 205 as a service to American Expressbusiness customers. In the case of the former, a customer 200 may bepresented a list of participating lending organizations (step 325). Acustomer 200 may be prompted to select one or more lendingorganizations, of which the customer 200 subscribes.

Depending on the types of credit the selected lending organization(s)offer, a customer 200 may be prompted to select the line of credit type(step 330) which customer 200 would like to add to an ACH 205 account.For example, information required for validating and processingtransactions based on an open line of credit may be different thantransactions performed against a credit card line of credit.

Following the selection of the line of credit type (step 330), customer200 may be presented a web form and prompted to enter account specificinformation relating to the line of credit (step 335). Line of creditinformation may include, for example, an account number, loan number,loan date, limit information, authorization credentials and the like.Personal information (step 320) and account information (step 335) maybe transmitted to ACH 205 where the information may be parsed, formattedand transmitted to CAS/FAS 275 in order to validate the account (step340). If an account is determined to not be valid (step 345), or ifauthentication credentials are not accurate, customer may again bepresented with a web form and prompted to enter line of creditinformation (step 335). However, if the account is valid (step 345) thenpersonal and account information may be transmitted to ACH 205 andstored in an enrollment database (step 350).

In addition to providing account specific data which may be required toidentify the account, a customer 200 may be required to enter additionalinformation in order prevent fraudulent use of the line of credit.Practitioners will appreciate that there are a number of methods knownin the art for ensuring that the customer 200 is the true owner of theline of credit. For example, when setting up a line of credit, acustomer 200 may be asked to provide their mother's maiden name, a passcode, a biometric or a question to which only the customer 200 wouldknow the answer.

In an exemplary embodiment, a customer 200 may be allowed to addmultiple credit lines to ACH 205 service. This may include multiplelines of credit provided by a single account manager and/or lines ofcredit provided by multiple account managers. If a customer has anadditional line of credit from the same creditor to add to ACH service(step 355), then customer may again be presented with a web form andprompted to select a line of credit type (step 330) where informationregarding the additional account may be collected, validated and stored.In another embodiment, a customer 200 may add lines of credit fromvarious participating account managers. Under this scenario, thecustomer 200 may be presented with a web form and prompted to select alending institution (step 325). The system may have routing and otherinformation stored in association with the pre-established selections orit may request any additional information needed to interface with theline of credit.

If customer 200 has no more lines of credit to add to an ACH service(step 355), then customer 200 may be prompted to select and enter a userID and/or password (step 360). A user ID and/or password selection maybe unique to the customer 200 and restrict unauthorized access to ACH205 service. A user ID and/or password selection may be transmitted toACH 205 where it may be validated (step 365) for proper form and toinsure that another customer 200 has not selected it previously. If theuser ID and/or password selection in not valid (step 370), then customer200 may again be prompted to select another user ID and/or password(step 360). If the user ID and/or password selection is valid (step 370)then customer 200 may be provided a webpage showing a summary of the newACH service (step 375). A summary may include information regardinglines of credit added to an ACH 205 as well as limits or balances.Customer 200 may be prompted to indicate whether or not they agree withthe information contained in the account summary. If customer 200 doesnot accept the summary (step 380), then any line of credit accountinformation that has been stored in an enrollment database 125 may beremoved and customer 200 may choose to re-enter the information, or exitfrom the ACH 205 website. If customer 200 accepts the informationcontained in the summary (step 380) then enrollment information may betransmitted to an ACH 205 to be stored with account information inenrollment database (step 385).

Following a successful enrollment, ACH 205 may activate a communicationscomponent (not shown) to generate and send an email message (or anyother communication via any network or device discussed herein) to a newACH customer (step 390). An email may contain summary information aswell as information regarding how to use the ACH 205 website to initiatea transfer transaction. Practitioners will appreciate that an ACH 205may initiate a postal mailing to a customer 200 containing likeinformation in the form of a confirmation and/or membership package.

FIG. 4 is a flow chart illustrating an exemplary method for interactingwith an ACH 205 in order to manage line of credit accounts and initiatetransfer transactions. A customer 200 who has an established accountwith ACH 205, may connect to an automated system (step 400) through anymeans known in the art and as discussed above in reference to FIG. 2.Customer 200 may be prompted to enter authentication information (step405) in order to authenticate the customer's 200 identity (step 410).Customer's 200 authentication information may be transmitted to ACH(step 445) to be verified against the information stored in enrolmentdatabase 125. Authentication information may include a user ID and/orpassword, which may be selected by a customer 200 or assigned by ACH 205at the time of enrollment. Practitioners will appreciate that manyadditional security measures may be employed in accordance with thelogin and authentication processes described herein.

Customer 200, who is not properly authenticated (step 415), eitherthrough user error or because of unauthorized use, may not be permittedto further access ACH 205 account options (step 420). An unauthorizedlogin attempt may initiate a prompt to determine if the customer 200 haspreviously enrolled (step 445). If customer has enrolled (step 450),then customer 200 may again be prompted to enter authenticationinformation (step 405). If customer 200 indicates that they have not yetenrolled for transfer service (step 450) then customer may be directedto an enrollment webpage (step 455). If customer is appropriatelyauthenticated (step 415) then customer 200 may be presented with serviceaccount management options (step 420). Service account options (step420) may comprise as user interface elements such as, for example,buttons, menu items, lists, hyperlinks as well as any other means knownin the art. Customer 200 may select to manage credit lines (step 425),initiate a line of credit transfer (step 430), and view transactionhistory (step 435). Each will be discussed in greater detail herein.

FIG. 5 is a flow chart illustrating a high level view of an exemplarymethod managing an transfer account. From an account management webpage(step 500) a customer 200 may select to edit lines of credit (step 505),edit deposit accounts (step 510) and configure payment (step 515).

Managing lines of credit (step 505) may enable customers 200 to managelines of credit, which will be made available for ACH 205 transfertransactions. As discussed in reference to FIG. 3, a customer 200 mayadd one or more lines of credit to an ACH 205 account during theenrollment process. A customer 200 may later choose to add additionallines of credit (step 520) in order to facilitate transfer transactionsthrough ACH 205. The steps which may be required to add one or morelines of credit to an ACH 205 account are illustrated and explained indetail in reference to FIG. 3.

Editing a line of credit (step 525) may enable a customer 200 to modifyaccount details. Many payment systems use a line of credit's billingaddress as another layer of validation in order to prevent unauthorizedor fraudulent use. While some information such as customer's 200 date ofbirth or social security number are more static and not subject tochange, a need may exist for a customer 200 to edit the information ifit was entered incorrectly during enrollment.

Deleting a line of credit (step530) may be desirable when a line ofcredit is no longer available due to closure of the line of creditaccount. A customer 200 may also decide to delete a line of credit froman ACH 205 account because they no longer want to barrow against theline of credit or because the balance has become too high. Deleting aline of credit would have the likely affect of removing all informationrelating to the line of credit from enrollment database 125 includingscheduled transfer transactions.

In addition to providing a customer 200 the ability to manage lines ofcredit (step 505), ACH 205 may enable customer's 200 to manage depositaccounts. A deposit account is any financial account, which acceptsthird-party deposits. These may include, for example, personal checkingand savings accounts, business accounts, investment accounts, retirementaccounts, loyalty accounts, merchant accounts, billing accounts (e.g.,utility accounts), recurring billing accounts or any other accountsassociated with an account number or a transaction device. A depositaccount is the destination for cash deposits originating via ACH 205line of credit transfer transaction.

ACH 205 may provide customers 200 with the ability to add depositaccounts at any time so that they may be available for fast andconvenient transfer transactions. These accounts may comprise one ormore deposit accounts that a customer 200 intends to transfer money intoon a semi-regular to regular basis. For example, a customer 200 who isalso a small business owner may have a payroll account with a bank. Ifthe customer 200 regularly transfers money into the payroll accountprior to payday, he may choose to add the deposit account to his ACH 205account in order to streamline the transfer process.

Adding a new deposit account (step 535) may include providing a web formand prompting customer 200 to enter information regarding a depositaccount. Such information which may be required by ACH 200 may include,name of the bank or credit union, account name, account number, routingnumber, and the like. This information may enable ACH 205 tosuccessfully transfer cash electronically from a line of credit to adeposit account.

ACH 205 may also enable customers 200 to edit deposit account data (step540). A stated above in reference to editing a line of credit (step525), deposit account data may change over time due to a changes in thestatement address, account name, telephone numbers, and the like. Ifdeposit account information, which may be stored in an enrollmentdatabase 125 does not match the information stored within the bankingsystem, a deposit may be rejected. Customers 200 may also choose to editinformation, which may not be critical to funds transfer into a depositaccount. Such information may be edited in the interest of thecustomer's 200 internal bookkeeping and audit procedures.

Deleting a deposit account (step 530) may be desirable when a depositaccount has been closed or when there is no longer a need to initiatetransfer transactions involving the deposit account. Further, when adeposit account is no longer needed, it may be desirable to eliminate itfrom an ACH 205 account to eliminate the possibility of inadvertenttransfers into the account. Deleting a deposit account may have thelikely affect of removing all information relating to the account froman enrolment database 125 including scheduled transfer transactions intothe deposit account.

From an account management (step 500) webpage, a customer 200 may chooseto configure payments (step 515). Configuring payments may define howand when transfers are made. Defining a maximum transfer amount (step550) may be desirable to help eliminate fraudulent transfers from bothauthorized ACH 205 account users as well as individuals who may breachthe security of the system. For example, a small business owner whofrequently transfers small amounts of cash from a line of credit to adeposit account may choose to set a transfer limit at $300.00.Therefore, the ACH 205 would reject any request for a transfer in excessof that amount. In another embodiment, a small business owner may definea maximum transfer amount that may be overridden by only limited ACHaccount users as designated by the business owner. The system may alsoincorporate known software which automatically or semi-automaticallymonitors transfers and flags unusual or inconsistent transfers. Thesystem may notify the consumer and/or request additional approval forcertain types of transfers. A more detailed description of access rightsand security will be discussed below in reference to transfer rules.

Configuring reoccurring payments (step 555) may allow customers 200 todefine a transfer transaction and setup a reoccurrence schedule.Reoccurring transfer transactions may be useful for transferring fundson a regular basis where the transfer amount is static. For example, acustomer 200 who chooses to utilize ACH 205 to pay a monthly lease for awork truck may do so by defining the deposit account details for theleasing company, selecting a line of credit from which to draw thepayment amount, defining the monthly payment amount and defining thedate for which the transfer is to occur for each month. ACH 205 may alsoallow a customer to define start and end dates for reoccurringtransfers.

Defining transfer rules (step 560) may enable a customer 200 to moreclosely control ACH 205 transfer transactions. A customer 200 may definerules globally which may apply to all transfers, or local rules to applyindividually to each line of credit and deposit account. One such rulemay enable a customer 200 to configure ACH 205 in order that onlypre-defined deposit accounts may be used in transfer transactions, thusreducing the possible occurrences of fraudulent transfers or transfersmade to unauthorized deposit accounts due to data entry errors.

Rules may also be defined in order to control which lines of credit maybe used for transfers into specific deposit accounts where multiplecredit lines and deposit accounts have been defined. For example, a rulemay be defined that stating that transfers into the deposit account ofan office supply store may only be initiated with credit line X andtransfers to a property manager for lease payments can only be made withcredit line Y. Additionally, defining which credit lines are used fortransfer transactions may be based on the amount of the transfer.Controlling which credit lines are used based on a deposit account ortransaction amount may be useful in controlling credit line balances andmaintaining the lowest interest rates possible.

In another embodiment, a customer 200 may define rules governing howtransactions, which exceed a line of credit, are conducted. If more thanone line of credit has been added via ACH 205, then a customer 200 maycreate a rule that states that if a transaction exceeds the credit limitof a first line of credit, then a second line of credit may be used totransfer the remaining transfer balance. Rules further governingtransfers in excess of a credit limit may include, for example, a ruledefining the order in which lines of credit are debited and a rule toreject transactions which exceed a credit limit of a primary credit linewhen the excess reaches a determined dollar amount.

Transfer rules may also be established defining who may execute transfertransactions. Varying security levels may be established grantingvarying access privileges to users of a single ACH 205 account. Forexample, a company CFO may administer an ACH 205 account for his companyand add various members of his accounting staff as ACH 205 account usersand assign them various roles. She may define rules allowing her leadaccountant to initiate transfers of up to $10,000 while other staffmembers are limited to transfers of up to $2,000. She may also definewho is allowed to access and/or modify the various ACH 205 accountmanagement components.

Referring back to FIG. 4, a customer 200 who is presented with serviceaccount options (step 420) may choose to view transaction history (step435). While not illustrated herein, practitioners will appreciate thatthere are a number of means for compiling, formatting, displaying andprinting transactional information. A report generator 130 may beemployed to extract data from an enrollment database 125 and format thedata in a manner to be displayed on a computer screen and/or printed.ACH 205 may enable customers 200 to define report parameters such as,for example, start and end date, transactions made to particular depositaccounts, transaction made against specific lines of credit, and thelike. ACH 205 may also provide customers with standard pre-definedreports as well as configurable or ad-hoc reports. Practitioners willalso appreciate that providing a view of transaction history (step 435)may be carried out through any number of commercially available reportgenerators, through custom software and/or hardware components, orthrough a combination thereof. Still further, it should be appreciatedthat reports may be generated from any combination of data stored on anycombination of databases, files, stored procedures and the like.

FIG. 6 is a flow chart illustrating an exemplary method for facilitatinga transfer of funds from a line of credit to a deposit account. Acustomer 200 may initiate a transfer (step 600) by connecting to ACH 205and entering authentication details as described previously. Customer200 may be first prompted to select from a list containing one or morepreviously configured line of credit accounts (step 605). Customer's 200selections of one or more line of credit accounts may represent theaccounts that will be debited when a transfer transaction has beencompleted. ACH 205 may next prompt customer 200 to select one or morepreviously defined deposit accounts (step 610) which are to receiveelectronically transferred funds. Customer 200 may then be prompted toenter a currency value (step 615) to transfer from a selected line ofcredit into a selected deposit account. If customer 200 had previouslyselected more than one line of credit (step 605), customer 200 may berequired to enter the currency value to be transferred from each line ofcredit individually. Likewise, if more than one deposit account wasselected (step 610), then customer 200 may be required to enter thecurrency value to be deposited into each deposit account individually.The system may also include financial management programs and softwarewhich automatically suggest or enter amounts to transfer based uponvarious personal financial conditions such as, for example, U.S. Ser.No. 10/709,703 which was filed on May 24, 2004 and is entitled PayYourself First, which is hereby incorporated by reference.

In another embodiment, and as discussed previously, a customer 200 mayhave defined rules regarding how a transaction exceeding a line ofcredit limit for a primary line of credit should be executed. Forexample, if a customer 200 selects her American Express business line ofcredit for a transfer transaction and the transfer amount exceeds theavailable line of credit, then a rule may state that her AmericanExpress personal line of credit should be used as a secondary line ofcredit to cover the deficiency.

ACH 205 may then transmit the transaction details to the backend systemsof the account manager(s) of the selected line(s) of credit. A limitservice 245 may query CAS/FAS 275 in order to verify that the transferamount requested does not exceed the available line of credit (step620). If it is determined that one or more selected lines of credit arenot sufficient for the transfer amount requested (step 625) thencustomer 200 may be informed of the deficiency and prompted to eitherselect a new line of credit (step 605), add one or more additional linesof credit, or change the transfer amount. However, if a rule existsdefining a sequence of two or more lines of credit to be used if adeficiency occurs, and if the combined lines of credit meet or exceedthe requested transfer amount, then the transfer would be allowed.

If limit service 245 determines that there is sufficient creditavailable for the requested transfer amount (step 625), then customer200 may be prompted to enter a verification code or password (step 630)unique to the one or more lines of credit. A verification code orpassword in addition to the ACH 205 login process may provide anadditional layer of security. For example, during cardless transactions,such as a payment over the telephone using a Visa credit card,cardmembers are often asked to provide a three digit security code whichis located on the back of a card. A verification code or password inaddition to the customer's 200 credentials and account information whichmay be stored in an ACH database 125 may be transmitted to ACH 205 whichmay initialize a verification service 240 in order to query theappropriate backend systems in order to validate the customer 200 andline of credit. If verification service 240 determines that theverification code is not valid (step 635) then customer 200 may beprompted to select a credit account (step 605) where they may select adifferent line of credit for the transaction.

If customer 200 entered a valid verification code or password (step 635)then customer 200 may be prompted to schedule a date and time for thetransfer to be executed (step 640). This may be useful for customer's200 who want to ensure that a deposit account is credited by a certaindate, however do not want to execute a transfer transaction too earlythereby reducing interest payments. Further, a customer 200 may schedulemultiple transfer transactions at a single time, rather that accessingACH 205 to execute each transfer transaction individually. However,customer 200 may select an option to indicate that the transfer is to beexecuted immediately, therefore would not need to enter schedulinginformation.

ACH 205 may enable customers 200 to schedule reoccurring transfers (step645). If customer 200 indicates that the current transfer should bescheduled on a reoccurring basis (step 650) then customer 200 may beprompted to enter the frequency of the transfer, define dates fortransfers to occur, and define a date for the first transfer and a datefor the final transfer.

Prior to executing the transfer transaction, a confirmation webpage(step 660) may be presented to customer 200 and include a description ofthe one or more line of credit accounts, description of the one or moredeposit accounts, amount of the transfer, current balance informationfor the one or more line of credit accounts, projected balance for theone or more line of credit accounts, fee disclosures and the like. If acustomer 200 reviews the confirmation and identifies an error or doesnot agree to the terms, the customer may choose to not confirm thetransfer transaction (step 665) and customer may again be prompted toselect a line of credit account (step 605) in order to correct errors ormay exit from the ACH 205. If the customer 200 confirms the transfertransaction (step 665), then ACH 205 may initiate card service 250 inorder to transact with the account manager's backend systems in order toexecute the transfer transaction, debiting the customer's 200 one ormore lines of credit (step 670) and crediting the specified one or moredeposit accounts (step 675).

On successful completion of the transaction, customer's 200 line ofcredit may be debited by sending a transaction to a Financial CaptureSystem and then passing the transaction to AR systems 270. Atransaction, formatted according to NACHA standards, may be transmittedto an Originating Depository Financial Institution (ODFI) for clearingat the customer's 200 financial institution. The funds may then bedeposited in the customer's 200 account during the next processingcycle.

Following a successful transfer transaction, ACH 205 may generate andsend a confirmation email notice to the customer's email account (step680). Confirmation email may contain details of the transaction as wellas provide a confirmation number that customer may print and file. Iffor any reason the transaction is not successful, ACH 205 may generateand send a transaction failure email notice to the customer's 200 emailaccount alerting customer 200 that the transfer transaction was notsuccessfully executed and may include a description of the problem andcontact information if technical support or account support is required.If a transfer transaction is executed immediately following the stepsrecited in FIG. 6, then a customer 200 may be provided immediate statusof the transfer transaction through a webpage.

Benefits, other advantages, and solutions to problems have beendescribed above with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any element(s) that maycause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as critical, required, or essentialfeatures or elements of any or all the claims. As used herein, the terms“comprises”, “comprising”, or any other variation thereof, are intendedto cover a non-exclusive inclusion, such that a process, method,article, or apparatus that comprises a list of elements does not includeonly those elements but may include other elements not expressly listedor inherent to such process, method, article, or apparatus. Further, noelement described herein is required for the practice of the inventionunless expressly described as “essential” or “critical”.

It should be understood that the detailed description and specificexamples, indicating exemplary embodiments of the present invention, aregiven for purposes of illustration only and not as limitations. Manychanges and modifications within the scope of the instant invention maybe made without departing from the spirit thereof, and the inventionincludes all such modifications. Corresponding structures, materials,acts, and equivalents of all elements in the claims below are intendedto include any structure, material, or acts for performing the functionsin combination with other claim elements as specifically claimed. Thescope of the invention should be determined by the appended claims andtheir legal equivalents, rather than by the examples given above.

1. A method comprising: debiting, by a computer based system fortransferring funds, a first line of credit transaction account a firstportion of funds; and debiting, by the computer based system, a secondline of credit transaction account a second portion of funds, whereinthe second portion of funds exceeds a first line of credit limit for thefirst line of credit transaction account.
 2. The method of claim 1,further comprising determining, by the computer based system, that thefirst line of credit transaction account is within a first predeterminedthreshold and the second line of credit transaction account is within asecond predetermined threshold.
 3. The method of claim 1, furthercomprising generating, by the computer based system, a transaction basedupon a first transaction request for a transfer of the first portion ofthe funds and based upon a second transaction request for the transferof the second portion of the funds.
 4. The method of claim 1, wherein arule allows a transaction request in response to the second portion offunds being within a second predetermined threshold of the second lineof credit transaction account.
 5. The method of claim 1, wherein a rulerejects a transaction request in response to the second portion of fundsexceeding a second predetermined threshold of the second line of credittransaction account.
 6. The method of claim 1, further comprisingcrediting, by the computer based system, a deposit account with thefunds.
 7. The method of claim 1, further comprising sending, by thecomputer based system, a transaction request to an automated clearinghouse financial capture system configured to capture and processtransaction details for at least one of the first portion of the fundsand the second portion of funds.
 8. The method of claim 1, wherein thedebiting at least one of the first line of credit transaction accountand the second line of credit transaction account comprises debiting ofat least one of currency, loyalty points, coupons, credits, securities,negotiable instruments, gift cards, digital funds, and foreign currency.9. The method of claim 1, wherein the funds include a first currency,and further comprising converting the funds to a second currency. 10.The method of claim 1, wherein the funds include a first type of funds,and further comprising converting the funds to a second type of funds,wherein the second type of funds comprises at least one of currency,loyalty points, coupons, credits, securities, negotiable instruments,gift cards, digital funds, and foreign currency.
 11. The method of claim1, wherein the first line of credit transaction account and the secondline of credit transaction account transfer funds to a deposit account,wherein the deposit account comprises at least one of: a personalchecking account, a savings account, a business account, an investmentaccount, a retirement account, a trust account, a loyalty account, amerchant account, a billing account, a recurring billing account and apayment system.
 12. The method of claim 1, further comprising at leastone of: applying rules, notifying a consumer, obtaining approvals,applying limits to the debiting and applying limits to crediting. 13.The method of claim 1, further comprising verifying that the secondportion of the funds do not exceed a second line of credit limit of thesecond line of credit account.
 14. The method of claim 1, furthercomprising transmitting, by the computer based system, the transactionto an originating depository financial institution for clearing.
 15. Themethod of claim 1, wherein the rules are pre-selected stored rules. 16.The method of claim 1, wherein the funds include a first currency, andfurther comprising converting the funds to a second currency.
 17. Themethod of claim 1, further comprising viewing transaction historyassociated with at least one of debiting the first line of credittransaction account with the first portion of the funds and creditingthe second line of credit transaction account with the second portion ofthe funds.
 18. The method of claim 1, wherein a transaction requestassociated with the debiting is formatted in a National AutomatedClearing House Association (NACHA) format.
 19. A system comprising: aprocessor for transferring funds, a tangible, non-transitory memoryconfigured to communicate with the processor, a debiting moduleconfigured to communicate with the processor and configured to debit afirst line of credit transaction account a first portion of funds; andthe debiting module further configured to debit a second line of credittransaction account a second portion of funds, wherein the secondportion of funds exceeds a first line of credit limit for the first lineof credit transaction account.
 20. An article of manufacture including anon-transitory, tangible computer readable storage medium havinginstructions stored thereon that, in response to execution by acomputer-based system for transferring funds, cause the computer-basedsystem to be capable of performing operations comprising: debiting, bythe computer based system, a first line of credit transaction account afirst portion of funds; and debiting, by the computer based system, asecond line of credit transaction account a second portion of funds,wherein the second portion of funds exceeds a first line of credit limitfor the first line of credit transaction account.